Recently, many organizations are becoming more involved in conducting business electronically (so called e-business), over the Internet, or on other computer networks. E-business calls for specialized applications software such as Electronic Bill Presentment and Payment (EBPP) and Electronic Statement Presentment (ESP) applications. To implement such applications, traditional paper documents have to be converted to electronic form to be processed electronically and exchanged over the Internet, or otherwise, with customers, suppliers, or others. The paper documents will typically be reformatted to be presented electronically using Hypertext Markup Language (HTML) Web pages, e-mail messages, XML messages, or other electronic formats suitable for electronic exchange, processing, display and/or printing.
For example, a credit card or utility company may decide to implement an EBPP service to allow its customers to view and pay bills on-line over the Internet. Any such EBPP implementation must be integrated into the organization's existing billing system. A straightforward seeming approach to integrating the billing systems would be to get the data from the existing billing system's database and use that data in the new e-business system. This approach, however, is not as simple as it may seem. Many legacy systems do not have a standard interface for data extraction and, moreover, the information required to present a document to a customer in electronic format does not exist in any one easily accessible database format. A telephone company, for example, might maintain three different databases feeding into its legacy billing application. The different database could be (1) a customer information database containing account numbers, calling plans, addresses and other customer profile information—this database including data that would be updated infrequently; (2) a rate and tariff database containing the rate structure used to calculate the cost of calls, which is typically based on geographic zones, time of day and the like—this database including data that would be updated periodically; and (3) a transaction database containing the transaction history of calls made by customers including number called, duration, and the like—this database including data that would be updated very frequently.
The various databases may be located on three separate and distinct computer systems (e.g. IBM mainframe, Tandem fault tolerant system, UNIX minicomputer, and so on) and in three different database formats (e.g. Oracle RDBMS, flat files, IMS database, and so on). Moreover, there is typically a great deal of application logic embedded in the billing system's legacy software code, which could be in the form of a COBOL program written in the 1960s, for calculating taxes, discounts, special calling charges, and so on. Because of these complexities, it is generally very difficult to recreate a bill for use in e-business from original data sources. Reference to the original data sources would generally require recreation of all of the functionality that exists in the individual organizations' existing billing systems. The cost and time needed to accomplish such recreation would generally be prohibitive.
Thus for use in legacy system integration and transition to e-commerce it can be more efficient to extract the desired information from print data generated by the legacy system as part of its conventional customer billing process. For this purpose, specialized software tools known as parsers have been developed to extract information out of the printstream data that is generated by the legacy document printing files. A run of printstream data may typically represent thousands of documents that are used to form thousands of bills to be sent to customers. As used in the legacy computer system, the printstream data is provided to a printer that prints out the thousands of documents (bills, statements, etc.) that are assembled and mailed to customers. The parser tools are programmed to recognize and extract data fields and information from the printstream so that such information may be used in an EBPP system.
A fair amount of printstream data will not be useful to the EBPP system, and will be accordingly ignored by the parser tools. For example, a bill printed by the legacy system may include graphics that are will not be used in the EBPP system. The corresponding graphics information in the printstream will thus be ignored.
Another example of printstream data that has typically been ignored is bar code data that is used for bar codes on documents produced by the legacy systems. The bar code data in the printstream will usually be in the form of an ASCII string that is converted to the familiar bar code form by a font on the printer. The bar codes are conventionally used for providing instructions to the machinery that assembles the printed documents into mail pieces, stuffs mail pieces into envelopes, and prepares the envelopes for mailing. The machines for preparing mass quantities of finished mail pieces from the printed documents are generally known as “inserters.”
The bar codes printed on documents may include information about how a mail piece should be assembled, as well as information about the intended recipient of the mail piece. Such information can include addressing, geographic, demographic and insert criteria, which information is used by a document inserting system to build a mail piece around the recipient's personalized document. The bar code may also include a “matchcode” that identifies the document as belonging to a particular mail piece. Consecutive documents having a same matchcode will be collated into the same mail piece. The bar codes may also include information on how many pages are in the mail piece, and a page number for a particular document in the sequence of documents in the mail piece.
The bar code may also include a reference pointer identifying a computer data file that further includes information about individual mail pieces to be assembled by the inserter. Such a computer data file is called a Mail Run Data File (MRDF) and typically an MRDF will include information about a large run of documents that are to be printed and processed by the inserter machine. The MRDF typically includes information and instructions more extensive that which is included in the bar code itself. An inserter machine will often receive instructions for assembling an individual mail piece based on information stored in the MRDF.
When processing documents to form mail pieces, an inserter system will scan the barcodes printed on the documents using known techniques. Using the information from the bar codes, the inserter will act upon the documents to accurately make the appropriate individualized mail piece. For example, the bar code may indicate whether a particular advertising insert should be included along with the bill being sent to the particular recipient. The bar code may also indicate that the document is part of a group of documents that needs to be collated together before being stuffed into an envelope.
Conventionally, since an EBPP system is not concerned with the manipulation of physical documents, bar code information embedded in the printstreams has generally been ignored.